Developer CD Series 1993…stman Always Clicks Twice/ADC Developer CD (1993-01) (''The Postman Always Clicks Twice'')_iso/Dev.CD 199301.iso/Development Platforms/CSMP Digests/csmp-v1-024.txt

Text File | 1992-11-18 | 46.4 KB | 1,262 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 20 Mar 92       Volume 1 : Issue 24

Today's Topics:

    List manager compress font
    C++ version 3 for MPW?
    Dev. OO SW for the Mac Book
    THINK C, TCL & Segmentation
    PROLOG for MAC ?
    ***EMERGENCY HELP NEEDED! ***
    GetPixBaseAddr()
    SndPlayFromFile in Async mode (?)
    Give it to me straight (probable FAQ)
    How can I hide certain folders from SFDialog?
    How to test an MDEF
    Menus in THINK C 5.0.2, best way??


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Matthew T. Russotto)
Subject: List manager compress font
Date: Mon, 10 Feb 92 15:41:46 GMT
Organization: University of Maryland, College Park, College of Engineering


Is there a way of turning off the change to compressed style that LDEF 0
does when a column is too narrow?  Right now I replaced StdText and StdTxMeas
with routines which call TextFace(thePort->txFace & ~compress), but that
seems ugly.
--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  List manager compress font
Date: 14 Feb 92 02:08:09 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Matthew T. Russotto) writes:
>
>Is there a way of turning off the change to compressed style that LDEF 0
>does when a column is too narrow?  Right now I replaced StdText and StdTxMeas
>with routines which call TextFace(thePort->txFace & ~compress), but that
>seems ugly.

If I were in your position, I'd probably just write my own LDEF rather
than patch two traps. Writing an LDEF is really simple, and writing one
that mimics the standard LDEF is the simplest of the simple. I've found
that looking at the LDEF with the ResEdit CODE editor and translating
it into C in THINK C to be really painless. Or, you can copy down the
source to the LDEF from ftp.apple.com. Since that LDEF is from 6.0.4,
it doesn't have the compressed text feature. Just assemble it and off
you go.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  List manager compress font
Date: 14 Feb 92 18:36:48 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Matthew T. Russotto) writes:
> Is there a way of turning off the change to compressed style that LDEF 0
> does when a column is too narrow?  Right now I replaced StdText and StdTxMeas
> with routines which call TextFace(thePort->txFace & ~compress), but that
> seems ugly.

Rewrite LDEF 0.  This is pretty trivial; it can probably be done with less
than one page of code.  And since you're doing it anyway, you'll get a
chance to add formatting features you probably wanted to add anyway.

Tim Dierks
MacDTS, but I speak for myself



---------------------------

From: [e-mail] (Per Lindgren)
Subject: C++ version 3 for MPW?
Date: 10 Feb 92 19:07:35 GMT
Organization: Dept. of computer systems, Uppsala university

--

I'm not a frequent reader of this group, so please bear with me if this is an
"old" question.

When are we going to see a 3.0 C++ for MPW?


  --------------------------------------------------------------------------
  |Per Lindgren              |    EMail: [e-mail]       |
  |Dept. of Computer Systems      |    Phone: [phone]           |
  |Uppsala University, SWEDEN     |    FAX: [phone]           |
  --------------------------------------------------------------------------



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  C++ version 3 for MPW?
Date: 13 Feb 92 20:09:33 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Per Lindgren) writes:
> I'm not a frequent reader of this group, so please bear with me if this is an
> "old" question.

> When are we going to see a 3.0 C++ for MPW?

If I would answer that I would be cleaning the streets of San Jose the
next week :-). Frankly speaking, speculation type questions will seldom
have any realistic answers, especially from Apple employees. And outside
Apple people may or may not have clues, which leads to MacWeek style
speculation which randomly touches reality base, especially in our industry
where things might change quite rapidly.

Kent



---------------------------

From: [e-mail] (Robert Dominy)
Subject: Dev. OO SW for the Mac Book
Date: 10 Feb 92 19:52:49 GMT
Organization: NASA Goddard Space Flight Center

Can anyone tell me whether the book _Developing Object Oriented Software
for the Macintosh_ by Jeff Alger and Neal Goldstein is being distributed
yet?

Also, are there any other references for their Solution-Based Modelling
development methodology?  All I've see so far is the blurb in the MADA
conference announcement.

- ------------------------------
Robert Dominy
NASA Goddard Space Flight Center



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  Dev. OO SW for the Mac Book
Date: 13 Feb 92 20:26:46 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Robert Dominy) writes:
>
> Can anyone tell me whether the book _Developing Object Oriented Software
> for the Macintosh_ by Jeff Alger and Neal Goldstein is being distributed
> yet?

What I've heard A&W has announced the availability of the book, and based
on the bookstore you might find it any day. I'm sure it's on sale at
the MADA Orlando conference later this month.

> Also, are there any other references for their Solution-Based Modelling
> development methodology?  All I've see so far is the blurb in the MADA
> conference announcement.

The book and their presentations are the references.

Kent Sandvik/DTS



---------------------------

From: [e-mail] (Daryl Spitzer)
Subject: THINK C, TCL & Segmentation
Date: 11 Feb 92 01:42:12 GMT
Organization: MIND LINK! - British Columbia, Canada

On page 120 of the THINK C Object-Oriented Programming
Manual it states that certain files must be in a resident segment.  Also,
I have begun using the Inside Out database engine, whose documentation
states that their routine ISOUnloadSeg (which calls _UnloadSeg for each of
their segments) should be called regularly, although certain segments
should be marked as pre-load and locked.

Am I correct in assuming that THINK C & TCL will not unload segments
itself unless I call _UnloadSeg?  (Unlike MacApp, which I gather will
unload any segment unless it's specified in a res! resource.)  How do I
mark a segment as pre-load and locked?  If the only way to do it is
through ResEdit, then I guess I'd be unable to lock segments when running
the program from the compiler?

Any pointers to parts of the THINK C User Manual, Inside Mac or THINK
Reference would be appreciated - I haven't been able to find the answers
to these questions there.
--
- -----------------------------------------------------------------
 [e-mail]     "Life isn't just, life just is."
         [e-mail]              -- Me  (I think.)
       [e-mail]
- -----------------------------------------------------------------



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  THINK C, TCL & Segmentation
Date: 14 Feb 92 05:25:07 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Daryl Spitzer) writes:
>
> On page 120 of the THINK C Object-Oriented Programming
> Manual it states that certain files must be in a resident segment.  Also,
> I have begun using the Inside Out database engine, whose documentation
> states that their routine ISOUnloadSeg (which calls _UnloadSeg for each of
> their segments) should be called regularly, although certain segments
> should be marked as pre-load and locked.
>
> Am I correct in assuming that THINK C & TCL will not unload segments
> itself unless I call _UnloadSeg?  (Unlike MacApp, which I gather will
> unload any segment unless it's specified in a res! resource.)  How do I
> mark a segment as pre-load and locked?  If the only way to do it is
> through ResEdit, then I guess I'd be unable to lock segments when running
> the program from the compiler?

You could use SetResAttrs() to specify resource attributes, as in this ad
hoc code:

short  attrs;
Handle myHandle;

myHandle = GetResource('CODE', 200);
if(myHandle != NULL){
   SetResAttrs(myHandle, attrs | resLocked | resPreLoad);
   LoadResource('CODE', 200); /* load the resource into memory */
}
/* fix the CODE resource on the disk */
   ChangedResource(myHandle); /* flag the resource for update */
   ReleaseResource(myHandle); /* discard it */

I just wrote it from top up my head, so if there are any bugs, please
correct them.

As for knowing what segments should be resident, it's really up to the
framework provider to make sure this information is available. In MacApp
resident code is usually flagged with a #pragma ARes statement (MacApp 3.0),
also Main and a couple of other segments are always resident.

Kent Sandvik/DTS



---------------------------

From: [e-mail] (Bernhard Knaus)
Subject: PROLOG for MAC ?
Organization: University of Austria
Date: Tue, 11 Feb 1992 13:30:38 GMT

Is there a PROLOG System for MAC? - If you know somthing about that,
please let me know that.

Thanks Bernhard Knaus
[e-mail]




- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Subject:  PROLOG for MAC ?
Date: 12 Feb 92 01:52:00 GMT
Organization: The University of Western Australia

In article <[e-mail]>, [e-mail] (Bernhard Knaus) writes:
>
> Is there a PROLOG System for MAC? - If you know somthing about that,
> please let me know that.
>
> Thanks Bernhard Knaus
> [e-mail]

Our department has been using Logic Programming Associates MacProlog for
the past 5 years.  It's now at version 3.5.  I really like it but I'm most
probably biased (-:

The reference manual gives their address as:

  Logic Programming Associates Ltd
  Studio 4, Royal Victoria Patriotic Building  [Love that building name (-: ]
  Trinity Road
  LONDON  SW183SX
  England

  Tel:     [phone]
  Fax:     [phone]
  Dialcom: 84:LPA001

I hope this helps.

Quinn "The Eskimo!"   <[e-mail]>   "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia



- -------------------------

From: [e-mail] (Tony Wingo)
Subject:  PROLOG for MAC ?
Date: 14 Feb 92 19:03:53 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Bernhard Knaus) writes:
>
> Is there a PROLOG System for MAC? - If you know somthing about that,
> please let me know that.
>
> Thanks Bernhard Knaus
> [e-mail]
>
There is a freeware prolog called Open Prolog from Trinity College in Dublin,
available via anonymous ftp from grattan.cs.tcd.ie, in the directory
tcd/mac.  The latest version I've seen is 1.0d28, so it is still under
development and has a few some rough edges. It has an interface that is
similar to MPW, and is fairly nicely done. It lacks things like full
toolbaox integration that you get with the commercial products.
But then, what do you want for free?

-tony

>>usual disclaimers apply<<



---------------------------

From: [e-mail] (Matt Weiser)
Subject: ***EMERGENCY HELP NEEDED! ***
Organization: Martin Marietta WIS
Date: Tue, 11 Feb 1992 14:16:28 GMT

We are creating a rather large application in MPW C++ and
have run into a Link Error:

Link:Warning: Size of global data area exceeds 65k. (Error 34)

We are getting "Out of Memory" errors at runtime, and think
this is the reason.  The linker lists this as a Warning -- is it
something that would cause the app to crash?  If it is not something
to really worry about, how do we suppress the linker warnings?
Looking at the .map file created there is something called "hasContents"
all over the place in the GlobalData Segment.  Does anyone know what
these are?  Do they have something to do with the virtual table access?

Do literals such as    char * string = "Where do I go in Memory?"
   get placed in the global data area ?

What exactly is placed in the Gobal data area ?
     String Literals ?
     Global variables ?
     Virtual tables for Classes ?

(Mac IIfx, MPW 3.2, System 7.0, 20 MB ram)

Any help is appreciated.  This thing is due Monday and if we don't get
it out, there will be 7 C++ programmers available....

Matt Weiser
Martin Marietta Western Internal Systems
[e-mail]
[phone]



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  ***EMERGENCY HELP NEEDED! ***
Date: 14 Feb 92 05:38:44 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Matt Weiser) writes:
>
> We are creating a rather large application in MPW C++ and
> have run into a Link Error:
>
> Link:Warning: Size of global data area exceeds 65k. (Error 34)

The default global data segment is 32k max, in order to get bigger
global data you need to use model far support with the linker and compiler.
This is available starting with MPW 3.2.

> We are getting "Out of Memory" errors at runtime, and think
> this is the reason.  The linker lists this as a Warning -- is it
> something that would cause the app to crash?  If it is not something
> to really worry about, how do we suppress the linker warnings?

I don't think these errors are corresponding, or then they correspond in
a loose way. "Out of Memory" would indicate lack of application space,
problems with the stack, and similar issues related to dynamic use of memory.
The global data space is once and for all setup during _RTInit time, so
I don't think >32k global data would cause memory problems during runtime
(I might be wrong...).

Check for any other typical memory problems, monitor memory use (StackSize(),
GetApplLimit()), watch what is going on in the heap with MacsBug and any
other debugger, and so on...

> Looking at the .map file created there is something called "hasContents"
> all over the place in the GlobalData Segment.  Does anyone know what
> these are?  Do they have something to do with the virtual table access?

> Do literals such as    char * string = "Where do I go in Memory?"
>    get placed in the global data area ?

Yes, if they are declared global, and they are awful when you want to
sell the application in Japan, Sweden or Germany, because the guy/girl
who is going to translate the menus and user interface messages into Swahili
or Finnish can't use ResEdit or any other tools provided by Apple for
internationalization. Please use STR# resources, you will get *less* global
data space use, and people in Iceland will be happy and send you a Christmas
present.

Now the -b2 might be a temporary bless in your case, it will trigger the compiler
to place string literals in code, and also overlay them (MPW 3.2 C forward...).
Anyway, STR resources is really the way to go in the long run.

> What exactly is placed in the Gobal data area ?
>      String Literals ?
>      Global variables ?
>      Virtual tables for Classes ?

It really depends on the environment and compiler. In the C++ case you will
get string literals, virtual tables, %_static_constructors_and_destructors resource,
static constructors/destructors. I have not encountered many cases in my career
where the global data segment is overloaded with stuff, not even in the MacApp case.
However if most of your strings are in the global data space, and any other possible
big arrays, I guess you could break the limits.


Kent Sandvik/DTS



---------------------------

From: [e-mail] (Brady Duga)
Subject: GetPixBaseAddr()
Date: 11 Feb 92 15:01:40 GMT
Organization: Center for Visual Science, U. of Rochester


I seem to be having some trouble with GetPixBaseAddr() (at least I think I'm
having trouble)...

When I call this with the portPixMap field of an offscreen drawing world,
I get the value 0xC88001B0. However, when I dereference the handle and look
at the baseAddr field, I get 0xC880007C. Is this discrepancy normal? I'm trying
to track down the cause of a bus error, and seems to be located somewhere
near a spot where I add an offset to the returned base address.

--Brady ([e-mail])



- -------------------------

From: [e-mail] (Eric Berdahl)
Subject:  GetPixBaseAddr()
Date: 14 Feb 92 19:29:59 GMT
Organization: Apple Computer

In article <[e-mail]>, [e-mail] (Brady Duga) writes:
>
>
> I seem to be having some trouble with GetPixBaseAddr() (at least I think I'm
> having trouble)...

Stop thinking.  You are having trouble.  There is a bug in the early versions
of 32-bit quickdraw.  Namely GetPixBaseAddr doesnUt.  It returns the first
word of the GrafPort in the high word of the result and the high word of
the baseAddr in the low word of the result.  In short, it doesnUt work.
Period.  The work-around is to fetch the baseAddr yourself.

This is fixed in System 7.0.

Eric



---------------------------

From: [e-mail] (Stephen McIntosh)
Subject: SndPlayFromFile in Async mode (?)
Date: 11 Feb 92 22:11:29 GMT
Organization: ACUS Australian Centre for Unisys Software, Sydney

I have tried unsuccessfully to play an AIFF file on disk using the
Async mode in SndPlayFromFile call.

I keep getting back an error saying insufficient hardware (-205 I think?).

If anyone has some working code that they can show me, it will help...

Thanks in advance
Stephen McIntosh
--
Sincerely
Stephen McIntosh
ACUS-The Australian Centre for UNISYS software
Phone:    [phone]    | ACSnet:   [e-mail]



- -------------------------

From: [e-mail] (Jim Reekes)
Subject:  SndPlayFromFile in Async mode (?)
Date: 15 Feb 92 00:41:26 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Stephen McIntosh) writes:
>
> I have tried unsuccessfully to play an AIFF file on disk using the
> Async mode in SndPlayFromFile call.
>
> I keep getting back an error saying insufficient hardware (-205 I think?).

SndPlayFromFile is not currently implemented on machines that do not have
the Apple Sound Chip.


- -----------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | All opinions expressed are mine, and
20525 Mariani Ave. MS: 81-EQ |  do not necessarily represent those
Cupertino, CA 95014          |  of my employer, Apple Computer Inc.



- -------------------------

From: [e-mail] (Stephen McIntosh)
Subject:  SndPlayFromFile in Async mode (?)
Date: 18 Feb 92 23:40:47 GMT
Organization: ACUS Australian Centre for Unisys Software, Sydney

[e-mail] (Jim Reekes) writes:

>In article <[e-mail]>, [e-mail] (Stephen McIntosh) writes:
>> I have tried unsuccessfully to play an AIFF file on disk using the
>> Async mode in SndPlayFromFile call.
>> I keep getting back an error saying insufficient hardware (-205 I think?).

I use an SE/30(includes an ASC) but the SndPlayfromFile (using NIL
as the snd channel) does not work. It only works for Sync playing.

IM VI states that the Snd Mgr will allocate a channel and play
it for you. The work around that appears to work is to allocate
a sound channel and then use this to play the sound
Async.

Hope this info is helpful.
Regards
Steve McIntosh
--
Sincerely
Stephen McIntosh
ACUS-The Australian Centre for UNISYS software
Phone:    [phone]    | ACSnet:   [e-mail]



---------------------------

From: [e-mail] (2915)
Subject: Give it to me straight (probable FAQ)
Date: 14 Feb 92 04:12:38 GMT
Organization: Concurrent Computer Corp. Westford MA.



I just bought a used SE30 for my wife to do her schoolwork and
for me to play with.  It's a nice machine but I hate not knowing
ANYTHING about how a Mac works under the hood.  Please email
suggestions to me regarding the best sources of information in
order that I can DMA the complete body of knowledge and Mac lore
into my brain.  I don't want cutesy beginner stuff, I want full
and detailed specs:  driver interfaces, filesystem, memory map,
boot procedure, etc....  I want everything you'd need to write
an OS for the Mac hardware and everything you'd need to write
a large and complex program for the existing Mac OS (not that
I currently plan to do either).  I bought The Macintosh Bible
but, although it's nice, it's not really what I'm looking for.

Thanks.
 ------------------------------------------------------------------
 Michael O'Donnell     [e-mail]     uunet!masscomp!mod
 Concurrent Computer Corporation     Westford, MA     [phone]
 NOTE:  Opinions I express are unlikely to be those of my employer.
 ------------------------------------------------------------------




- -------------------------

From: [e-mail] (Cameron Javad Esfahani)
Subject:  Give it to me straight (probable FAQ)
Date: 14 Feb 92 20:48:23 GMT
Organization: University of Michigan

You want to get the Inside Macintosh Volumes I-VI from Addison-Wesley.
They tell you everything you need to know about programming the
Macintosh.

--
Cameron Esfahani        LED...ZEPPELIN...IS...BACK!!
[e-mail]        I admit it, I broke Mike's lamp, I'm sorry...
VizLab, USENET, Macintosh,    "Alright!  Let's do it"
X-windows CAEN Support



- -------------------------

From: [e-mail] (Scott Bronson)
Subject:  Give it to me straight (probable FAQ)
Date: 17 Feb 92 02:16:06 GMT

In <[e-mail]> [e-mail] (Cameron Javad Esfahani) writes:

>You want to get the Inside Macintosh Volumes I-VI from Addison-Wesley.
>They tell you everything you need to know about programming the
>Macintosh.

IM doesn't even come close to telling you everything you need to know
about programming the Macintosh.  Tech Notes and Tech Docs supplement IM,
APDA produces all kinds of other documents on more vertical topics (how
to write your own external file system) etc...

Inside Macintosh is a great place to begin, but it sure doesn't go the length.


   - Scott            +----------------: SCOTT BRONSON :-----------------+
+---------------------|  [e-mail]    [e-mail] |
| Programming in C is | 6850 El Colegio Road #234; Goleta, CA 93117-4300 |
| glissading indoors. +==================================================+
+=========================+



- -------------------------

From: [e-mail] (David Casseres)
Subject:  Give it to me straight (probable FAQ)
Date: 17 Feb 92 17:43:20 GMT
Organization: Apple Computer

In article <scott.698292966@mcl>, [e-mail] (Scott Bronson) writes:
>
> In <[e-mail]> [e-mail] (Cameron Javad Esfahani) writes:
>
> >You want to get the Inside Macintosh Volumes I-VI from Addison-Wesley.
> >They tell you everything you need to know about programming the
> >Macintosh.
>
> IM doesn't even come close to telling you everything you need to know
> about programming the Macintosh.  Tech Notes and Tech Docs supplement IM,
> APDA produces all kinds of other documents on more vertical topics (how
> to write your own external file system) etc...
>
> Inside Macintosh is a great place to begin, but it sure doesn't go the length.

My 2 cents:  Inside Mac is the *reference* work on the Mac, not a place to
begin!  Try Chernicoff's Macintosh Revealed books, or something similar.

David Casseres



---------------------------

From: wdburns@edu (Bill Burns)
Subject: How can I hide certain folders from SFDialog?
Organization: CCLI Macintosh Lab.
Date: Fri, 14 Feb 1992 06:27:21 GMT

Hi all -
  I've got a problem that I'm not sure how/if I can change...

The local drives on our network has two folders (one includes the System Folder)which are invisible from the Finder, but which show up in certain programs'
SFDialog boxes - namely MS-Word.  I'd really like to NOT LET THIS HAPPEN, as
I'm sure any other network administrators would agree.  Basically I'd like
either SFDialog or the programs to care about folder/file settings.  I'm not
sure if the "Desktop" file shows up or not, but I'd like to not let the user
know about / enter certain directories on teh local disk.

Does anyone know why SFDialog disregards the folder attributes?
Is there an easy way around this?
Should I be settings some OTHER bits?

Note: machines in question are either running system 6.0.x or system 7.

Thanks in advance!

Bill Burns ([e-mail])
Mac Technical Consultant, CCLI Lab
Michigan Tech. University





- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  How can I hide certain folders from SFDialog?
Date: 17 Feb 92 01:52:06 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, wdburns@edu (Bill Burns) writes:
>
> Hi all -
>   I've got a problem that I'm not sure how/if I can change...
>
> The local drives on our network has two folders (one includes the System Folder)
> which are invisible from the Finder, but which show up in certain programs'
> SFDialog boxes - namely MS-Word.  I'd really like to NOT LET THIS HAPPEN, as
> I'm sure any other network administrators would agree.  Basically I'd like
> either SFDialog or the programs to care about folder/file settings.  I'm not
> sure if the "Desktop" file shows up or not, but I'd like to not let the user
> know about / enter certain directories on teh local disk.
>
> Does anyone know why SFDialog disregards the folder attributes?
> Is there an easy way around this?
> Should I be settings some OTHER bits?
>
> Note: machines in question are either running system 6.0.x or system 7.
>
> Thanks in advance!

    This is due to a limitation in the original SFGetFile and SFPGetFile calls, which
is that there's no way to filter folders, only files.  Basically, when you call
GetFile, you can either tell it do display some number of file types (including none)
by passing a non-negative count for your file types list, or you can say that you'll
filter the files yourself, by passing -1 as your file type count.  Normally invisible
files and folders are excluded from the file list, but when you provide a filter
function, Standard File allows the programmer to control their display.  However,
because the entire architecture dates from pre-HFS, flat file system, days, folders
are not passed to the filtering function to examine; thus, there's no way for a
program to keep invisible folders from being displayed.  As far as I know, there's
no easy way around it; the only people I know of to have worked around it did it
by patching PBGetCatInfo to totally skip invisible folders, not a task for the faint
of heart.
    All this was fixed with the addition of the new StandardGetFile and CustomGetFile
commands in System 7, but it will probably be a while before programs begin to use
these calls exclusively, and there's not much hope for System 6 at all.

Tim Dierks
MacDTS, but I speak for myself



---------------------------

From: [e-mail] (Ramon Felciano)
Subject: How to test an MDEF
Date: 14 Feb 92 17:45:51 GMT
Organization: SUMMIT, Stanford U. Medical Media & Information Technologies

Hi!

Is there any convenient way of testing an MDEF? I'm writing one, and right
now I'm compiling it into a code resource, quitting THINK Pascal, using
Resedit to copy it into my dummy program, and launching that program
(usually to a crash!).

Isn't there a way of testing this from within THINK Pascal?

Thanks.

Ramon M. Felciano
Associate Director, SUMMIT
Stanford University Medical Media and Information Technologi



- -------------------------

From: [e-mail] (David Phillip Oster)
Subject:  How to test an MDEF
Date: 17 Feb 92 05:57:16 GMT
Organization: Whole Earth 'Lectronic Link, Sausalito, CA

MDEFs can be debugged from inside applications by allocating a menu with a
proc id of 9 (the standard menu proc), then storing into its proc field,
a handle, length 6 bytes, consisting of the 68000 machine language value of
a JMP instruction followed by the address of the MyMDEFProc(). You may even
wantt to use this technique in the finished application, since that gives the
MDEF procedure access to the global variables of the application, although,
given what apple has done to uis in the past, I'd save and restore register A5
to make sure our MDEF is looking at the right set of global variables.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- [e-mail] = {backbone}!well!oster



- -------------------------

From: [e-mail] (Lloyd Lim)
Subject:  How to test an MDEF
Date: 18 Feb 92 10:52:02 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <[e-mail]> [e-mail] (David Phillip Oster) writes:

>MDEFs can be debugged from inside applications by allocating a menu with a
>proc id of 9 (the standard menu proc), then storing into its proc field,
>a handle, length 6 bytes, consisting of the 68000 machine language value of
>a JMP instruction followed by the address of the MyMDEFProc(). You may even
>wantt to use this technique in the finished application, since that gives the
>MDEF procedure access to the global variables of the application, although,
>given what apple has done to uis in the past, I'd save and restore register A5
>to make sure our MDEF is looking at the right set of global variables.

If you do this, you're writing self-modifying code and you'll have to
flush the instruction cache or you'll break on Quadras.

I've heard of two better ways of dealing with this:

1)  Store the address at the end of the code.  Use LEA and MOVE to shove it
into A0, for example, and then JMP to it.

2)  Store the address in some other convenient place.  Most defprocs have
a refcon or data field that they can access.  Menus are a problem because
they don't have either.  You could cram it into the menuData somewhere but
you should make sure that your menu items still flash correctly.  (See
Tech Note 222.)

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  How to test an MDEF
Date: 17 Feb 92 01:28:35 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Ramon Felciano) writes:
> Is there any convenient way of testing an MDEF? I'm writing one, and right
> now I'm compiling it into a code resource, quitting THINK Pascal, using
> Resedit to copy it into my dummy program, and launching that program
> (usually to a crash!).
>
> Isn't there a way of testing this from within THINK Pascal?

Use one of my favorite tricks, the 6-byte resource trick.  Create a test
program which uses your MDEF.  Add your MDEF function to the program, then
create a 6-byte resource of type MDEF, with the appropriate resoure ID,
which you add to your program.  In your program, load the MDEF and fill
the first two bytes with $4EF9 and the last four bytes with a pointer to
your MDEF function (which you link in with your code).  The $4EF9 is a JMP
instruction; this way, the menu manager will attempt to load this resource
and call it; it will then jump to your code, in your program.  Thus, you
can compile and test, compile and test, without building a custom resource
each time.  Furthermore, you can now debug your resource with the standard
source code debugger.

I almost forgot- it's very important that you flush the instruction cache
after filling in the 6-byte resource, or your program will crash on a
68040.

Tim Dierks
MacDTS, but I speak for myself.



- -------------------------

From: quesnel@ems (Rene Quesnel)
Subject:  How to test an MDEF
Date: 19 Feb 92 00:16:55 GMT
Organization: Faculty of Music, McGill University

In article <[e-mail]> [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
>Use one of my favorite tricks, the 6-byte resource trick.  Create a test
>program which uses your MDEF.  Add your MDEF function to the program, then
>create a 6-byte resource of type MDEF, with the appropriate resoure ID,
>which you add to your program.  In your program, load the MDEF and fill
>the first two bytes with $4EF9 and the last four bytes with a pointer to
>your MDEF function (which you link in with your code).

*** Part of the text deleted ***

>I almost forgot- it's very important that you flush the instruction cache
>after filling in the 6-byte resource, or your program will crash on a
>68040.

Can you expand a little bit on that last comment? Why is it necessary to
flush the instruction cache? how do you dot it? Does this apply to
CDEF's as well?

Thanks,

Rene Quesnel
[e-mail]



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  How to test an MDEF
Date: 19 Feb 92 04:59:34 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
>
>Use one of my favorite tricks, the 6-byte resource trick....

>I almost forgot- it's very important that you flush the instruction cache
>after filling in the 6-byte resource, or your program will crash on a
>68040.

It's not *that* important - unless some sadist breaks the Toolbox, it's not
an absolute necessity to flush the caches when installing a custom defproc
of any sort on the fly, because it seems that all paths on the way back from
loading a defproc end up flushing the cache. Stylistically, you might want
to flush the cache, but it isn't essential.

To see the 6-byte resource trick in action, look at the ObjectDraw sample that
ships with THINK Pascal, or look in the "MDEF (LS Pascal)" folder on every
developer CD that's been produced.

R.



--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  How to test an MDEF
Date: 19 Feb 92 09:34:02 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> quesnel@ems (Rene Quesnel) writes:

   >create a 6-byte resource of type MDEF, with the appropriate resoure ID,
   >which you add to your program.  In your program, load the MDEF and fill
   >the first two bytes with $4EF9 and the last four bytes with a pointer to
   >your MDEF function (which you link in with your code).

   >I almost forgot- it's very important that you flush the instruction cache
   >after filling in the 6-byte resource, or your program will crash on a
   >68040.

   Can you expand a little bit on that last comment? Why is it necessary to
   flush the instruction cache? how do you dot it? Does this apply to
   CDEF's as well?

Anywhere where you generate or modify code on the fly (as here,
where you generate a JMP intruction) you have to flush the cache,
since the code is generated into data space, and thus may not be
"seen" if the code cache already contains the previous values of
those memory locations.

Flushing the cacle is done through calling _CacheFlush. Of course,
you must check for availability, but a "cheap" check might be to
assume any mac with processor >= 68020 has _CacheFlush.

Oh, some routines, such as GetResource and BlovkMove for more than
12 bytes flush the cache for you. It's all detailed in the technote
"cache as cache can."



--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

Subject:  How to test an MDEF
From: [e-mail] (Tim Hammett)
Date: Thu, 20 Feb 1992 01:42:01 GMT
Organization: University of Auckland, New Zealand.

In article <[e-mail]> [e-mail] (Tim Dierks, ToyMeister, Cray abuser) writes:
>
>Use one of my favorite tricks, the 6-byte resource trick....

>I almost forgot- it's very important that you flush the instruction cache
>after filling in the 6-byte resource, or your program will crash on a
>68040.

I'm confused by the above. If the resource/memory/whatever manager didn't
handle it for you, would you want to flush the instruction cache, the data
cache, or both? I would have thought both - the data cache to ensure that
the changes you made get written back into RAM, and the instruction cache
in case there was some code where the resource was previously which is
still in the cache.

Thanks in advance to anyone who can enlighten me...

      --- Tim.
--

Tim Hammett, Department of Botany, Auckland University, New Zealand.
e-mail: [e-mail]       Phone: [phone] x8365



---------------------------

From: [e-mail]
Subject: Menus in THINK C 5.0.2, best way??
Date: 14 Feb 92 05:16:33 GMT
Organization: BC Systems Corporation

I've got an interesting problem/question.  I'm desperately trying to learn C
with THINK C 5.0.2 on a Mac Plus with 4MB RAM, and System 7.0* (w/ tuneup).
I'm reading 2 books currently on Mac C programming for THINK C.  They are
"Programming for System 7" by Gary Little and "Macintosh C Programming by
Example" by Thom Hogan and Kurt WQ.G. Matthies (the 2 that were writing the
"Power Programming" column in MacUser awhile ago.

My problem is this: in the book on System 7, the Shell.c file seems to treat
menus (and their handles) locally.  When a MouseDown event occurs in the
MenuBar, he calls AdjustMenus(); to resetup the menus all over again (ie: he
enables and disables the items, etc).  His code looks something like this:

/* from the EventLoop */

...
switch ( event->what ) {
    case MouseDown:
        windowPart = FindWindow( event->where, &window );
        switch ( windowPart ) {
            AdjustMenus();    /* prepare menu items first */
            DoMenuCommand ( MenuSelect( event->where ) );
            break;
....

/* now the adjust menus */

void AdjustMenus( void )
{
    WindowPtr    wp;
    MenuHandle    fileMenu, editMenu, specialMenu;

    wp = FrontWindow();

    fileMenu = GetMHandle( mfile );
    editMenu = GetMHandle( medit );
    specialMenu = GetMHandle( mSpecial );

    DisableItem...
    ..
}

Now in the other book by Thom Hogan, it treats the menus as gloabals (the way
the should as far as I know.  That's the way I did it in a THINK Pascal program
I wrote!!!!)

Which way is best...or is there a "best" way??????
Any help is muchly appreciated!!!!

--
[e-mail]
British Columbia, Canada



- -------------------------

Subject: Think C 5.02 multisegm. DA bug???
From: [e-mail]
Date: 18 Feb 92 09:21:54 CST
Organization: Brandon University, Brandon, Manitoba, Canada

Does anybody know anything about a bug in Think C 5.02 (and 4) related to the
header used for deskaccessories?
I am writing a multisegment deskaccessory. I usually cannot make it cause a
system error except in a very specific kind of circumstances:
On an LC (and possibly other machines, but not on a Plus) running system 6.07
without MF (and possibly other system configurations): After the DA has been
freshly installed, i.e. the computer has not been rebooted since the DA was
moved into the System by DA mover 3.8 or 4.1 and the DA was not already in
the system, selecting the DA from the Apple menu causes an immediate
"illegal instruction" system error: the programme tries to execute an
instruction not in any heap zone but happens to be 2 bytes off the proper
allignment.
This error occurs before any of my instructions are reached, i.e. a
Debugstr call at the beginning of main is never executed.
--
Thanks for any hints I could be given!
- -----------------------------------------------------------------------------
Andreas Guelzow  Dept. of Mathematics & Comp. Sc. Brandon University MB Canada
[e-mail]



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Menus in THINK C 5.0.2, best way??
Date: 17 Feb 92 18:38:49 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] writes:
> My problem is this: in the book on System 7, the Shell.c file seems to treat
> menus (and their handles) locally.  When a MouseDown event occurs in the
> MenuBar, he calls AdjustMenus(); to resetup the menus all over again (ie: he
> enables and disables the items, etc).  His code looks something like this:
[...]
> Now in the other book by Thom Hogan, it treats the menus as gloabals (the way
> the should as far as I know.  That's the way I did it in a THINK Pascal program
> I wrote!!!!)
>
> Which way is best...or is there a "best" way??????
> Any help is muchly appreciated!!!!

Well, there's never a "best" way in anything as nebulous as Mac programming....

Anyway, many people take the approach of only setting up the menus just as the user
clicks in the menu bar, because it's simple (you localize all your code) and fast
enough that the user usually doesn't notice any delay.  This is considered an advantage
over enabling and disabling items every time the user takes an action.  Basically,
it's up to you, and either approach could be better depending on your situation.  For
example, if I was writing an object drawing program, I'd probably enable on menu select,
because it's going to be more convenient than dealing with a lot of menu items ("Move
Forward", "Move Backward", line size, type size, on and on...) every time the user
selects an object.  But if I was writing a simple program with one window and three
menu items, "Open", "Close" and "Quit", I'd just enable them and disable them as it
goes.

Note that the one element that is always visible is the menu bar titles.  If you disable
all the items in a menu, strictly speaking, you are supposed to disable the menu item
itself.  If you use the "enable on mousedown" method, this could lead to the user
clicking on a menu, only to find it disable itself under the mouse, just as the user
intended to use it.  This could be somewhat disconcerting, so most "on menu click"
method programs never disable menu titles, even if all the items are disabled; this
could be construed to be in violation of strict interface guidlines.

Tim Dierks
MacDTS, but I speak for myself



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Menus in THINK C 5.0.2, best way??
Date: 17 Feb 92 18:39:02 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] writes:
> My problem is this: in the book on System 7, the Shell.c file seems to treat
> menus (and their handles) locally.  When a MouseDown event occurs in the
> MenuBar, he calls AdjustMenus(); to resetup the menus all over again (ie: he
> enables and disables the items, etc).  His code looks something like this:
[...]
> Now in the other book by Thom Hogan, it treats the menus as gloabals (the way
> the should as far as I know.  That's the way I did it in a THINK Pascal program
> I wrote!!!!)
>
> Which way is best...or is there a "best" way??????
> Any help is muchly appreciated!!!!

Well, there's never a "best" way in anything as nebulous as Mac programming....

Anyway, many people take the approach of only setting up the menus just as the user
clicks in the menu bar, because it's simple (you localize all your code) and fast
enough that the user usually doesn't notice any delay.  This is considered an advantage
over enabling and disabling items every time the user takes an action.  Basically,
it's up to you, and either approach could be better depending on your situation.  For
example, if I was writing an object drawing program, I'd probably enable on menu select,
because it's going to be more convenient than dealing with a lot of menu items ("Move
Forward", "Move Backward", line size, type size, on and on...) every time the user
selects an object.  But if I was writing a simple program with one window and three
menu items, "Open", "Close" and "Quit", I'd just enable them and disable them as it
goes.

Note that the one element that is always visible is the menu bar titles.  If you disable
all the items in a menu, strictly speaking, you are supposed to disable the menu item
itself.  If you use the "enable on mousedown" method, this could lead to the user
clicking on a menu, only to find it disable itself under the mouse, just as the user
intended to use it.  This could be somewhat disconcerting, so most "on menu click"
method programs never disable menu titles, even if all the items are disabled; this
could be construed to be in violation of strict interface guidlines.

Tim Dierks
MacDTS, but I speak for myself



---------------------------

End of C.S.M.P. Digest
**********************